home *** CD-ROM | disk | FTP | other *** search
- Path: ccshst05.cs.uoguelph.ca!ccshst01!thay
- From: thay@uoguelph.ca (Toby K Hay)
- Newsgroups: comp.lang.c
- Subject: Re: Segmentation Fault ???
- Date: 10 Mar 1996 19:33:23 GMT
- Organization: University of Guelph
- Message-ID: <4hvaq3$n8f@ccshst05.cs.uoguelph.ca>
- References: <4hsa7i$en3@wraith.its.uow.edu.au> <4huis1$cm2@ccshst05.cs.uoguelph.ca> <4hv75jINNpss@keats.ugrad.cs.ubc.ca>
- NNTP-Posting-Host: ccshst01.cs.uoguelph.ca
- X-Newsreader: TIN [version 1.2 PL2]
-
- Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
-
- : It means that you are making errors in your code that the Turbo C environment
- : doesn't catch. The bus error is likely caused by invoking
- : implementation-specific behavior that is in contravention to standard C:
- : converting a pointer to one that has a stricter alignment. On many of the
- : processors used in UNIX workstations, the address of a long word has to be
- : divisible by four. On a 68000 processor, the address of a 16-bit word has to be
- : divisible by two.
- : If you fail to meet these alignment restrictions, the hardware will trigger an
- : exception, and the UNIX kernel will send a SIGBUS signal to your program.
-
- Would lint catch this for me, or will I have to learn about alignment
- restrictions to run my program?
-
- : A ``segmentation fault'', (SIGSEGV signal), on the other hand, is caused by
- : accessing illegal memory, such as dereferencing a null pointer, reaching past
- : the limits of your malloc heap or stack and so forth.
-
- From three replies I received via E-mail I understand that accessing
- illegal memory is almost certainly caused by using uninitialized pointers
- - something I will check my code for again. But what determines the
- limits of my malloc heap, stack, and so forth? Can I request more memory
- for these at the command line when I start the program?
- Toby Hay thay@uoguelph.ca
-